Advances in plasma processing have provided for growth in the semiconductor industry. Plasma processing has continued to evolve as manufacturing companies attempt to stay competitive in the semiconductor industry. To be competitive, a manufacturer has to have access to a vast array of data in order to maintain and upkeep its tools and/or to troubleshoot problems that may arise.
During processing, the data (e.g., gas type, temperature, processing time, voltage, pressure, etc.) may be collected. Generally, the data that is gathered for each processed substrate may first be stored at the tool level. Since the tool may have limited memory capacity, the data may be forwarded to a server for storage. The data may be stored at the server until the data is needed for analysis.
In a typical semiconductor environment, a manufacturer may have a plurality of tools connected to a plurality of servers, as shown in FIG. 1. For this semiconductor environment, data collected by each tool (Tool1, Tool2, Tool3, Tool4, Tool5, and Tool6) may be either stored at a server 104 or a server 106. In an example, server 104 may be associated with a tool cluster 108. Tool cluster 108 may include Tool1, Tool2 and Tool 3. Similarly, server 106 may be associated with a tool cluster 110, which may include Tool4, Tool5, and Tool6.
Server 104 and server 106 may have various modules that may be employed to store and/or retrieve the data, as shown in FIG. 2. In an example, data collected during substrate processing by Tool1 of tool cluster 108 may be forwarded to server 104. In server 104, the data may first be stored at a memory 206 (e.g., disk storage, etc.). An indexing application 204 (e.g., Lam AutoArchiver) may then index the data stored at memory 206 and stored the indexed data at a database 208.
In another example, data collected during substrate processing by Tool6 of tool cluster 10 may be forwarded to server 106. In server 106, the data may first be stored at a memory 222 (e.g., disk storage, etc.). An indexing application 220 (e.g., Lam AutoArchiver) may then index the data stored at memory 222 and stored the indexed data at a database 224.
Databases 208 and 224 are examples of full database management systems (e.g., Microsoft SQL Server, Oracle, etc.) capable of handling the different types of data that may be collected during substrate processing. Databases 208 and 224 may index the data that are stored in server 104 and 106, respectively.
FIG. 3 shows an example of indexing for database 208. Data files, which may be stored at a local memory 206, may include a plurality of data files including data files 302a, 302b, 302c, and the like. File path 308, such as /LamData/ToolA/data/<module>/<type>/<date>/substrate 1, for example, may be stored as an index in database 208. In this example, module may refer to a tool module (e.g., processing module, transfer module, etc.). Also, type may include, for example, data lot file, lot history file, optical spectrum file, and the like.
In addition to indexing file path 308, data stored in each data file may also be indexed and stored in database 208. In an example, database 208 may also index the following: module 310 (e.g., processing module, transfer module, etc.), tool 312 (name of the tool and/or identification number of the tool), recipe 314 (recipe used to process the substrate), lot id 316 (identification number for the lot of substrates that had been processed), start time 318 (processing begin time), substrate ID 320 (identification number for the substrate), and the like.
Referring back to FIG. 2, in order for a user to retrieve a data file, the user may have to be able to locate the storage location of the data file. One way the user may be able to locate the data file is by remembering where the data file has been stored. However, as can be seen in FIG. 3, the file path for a data file may be long and difficult to remember. Thus, relying upon a user's memory to locate a data file may be unrealistic, especially if the data has been collected weeks or even months ago. Also, the user that may be requesting for the data file may not be the same person who collected the data.
To facilitate the searching process, software such as Lam DataExplorer (Lam Research Corporation, Fremont, Calif.) may be employed to search for the data file. Even with software such as Lam DataExplorer, for example, the user may still have to dig through a plurality of data files on each server in order to find the exact data file(s) that the user may need in order to perform his analysis.
Consider the situation wherein, for example, during processing on Jun. 10, 2006 from Tool6, a plurality of data has been collected and has been stored on server 106. Two months later, a problem has been identified and to analyze the problem, the data from Jun. 10, 2006 from Tool6 need to be retrieved. To retrieve the data, a user at a computer 102 may have to identify the storage location of the data.
First, the user may search server 104 for the required data files. To search for the data file, the user may employ an open database connectivity (ODBC) application module 214 as an interface to search through the index information about the data stored on database 208. If the data is stored on local memory 206, then the user may be able to retrieve the data file from memory 206 via an ftp server 216. In this example, the data file is not stored on server 104.
Since the data file is not stored on server 104, then the user may next search server 106. Similarly, to search for the data file, the user may employ an ODBC application module 232 as an interface to search through the index information about the data stored on database 224. If the data is stored on local memory 222, then the user may be able to retrieve the data file from memory 222 via an ftp server 230.
Server 104 and server 106 may also include additional modules. These modules enable users at a web browser computer 202 (e.g., Lam Report Browser, Equipment Information Reporter, etc.) to retrieve data files. In an example, the user at web browser computer 202 may want to retrieve a data file. The user may employ a web application 218 to access the indexed data that may be stored on a web-prepared database 212. Data stored on web-prepared database 212 may have been extracted from database 208 and converted into a web format by importer application 210. Similarly, server 106 may include a web application 234, a web-prepared database 228, and an importer application 226.
There are several disadvantages with the prior art architectural arrangement for storing and retrieving data. In an example, a user is responsible for keeping track of the location of the data file. If the user is unable to do so, then the user may have to spend a considerable amount of time searching through a plethora of data files on each server in order to locate and retrieve the required data file. This method of locating a data file can be time consuming and frustrating if the user is working within a large and complex environment.
Also, the cost associated with running a full database management system can become very expensive. First, an expensive licensing fee has to be purchased. Also, expensive computer hardware with sufficient processing power may have to be provided in order to accommodate the type of processing that a full database management system may require. In the prior art architectural arrangement, each server may have to run its own full database management system. Thus, the costs of running multiple databases on multiple servers may quickly compound for a company that has a complex network infrastructure with a plurality of servers